I also like the idea of having auto-completion and cleaner implementation of the constants.
However, an everyday manim scene would look like this:

        GraphScene.setup_axes(self)
        # width of edges
        self.x_axis.set_stroke(width=2)
        self.y_axis.set_stroke(width=2)
        # color of edges
        self.x_axis.set_color(RED)
        self.y_axis.set_color(YELLOW)
        # Add x,y labels
        func = TexMobject("\\sin\\theta")
        var = TexMobject("\\theta")
        func.set_color(BLUE)
        var.set_color(PURPLE)
        func.next_to(self.y_axis,UP)
        var.next_to(self.x_axis,RIGHT+UP)
        # Y labels
        self.y_axis.label_direction = LEFT*1.5
        self.y_axis.add_numbers(*[-1,1])
        #Parametters of x labels
        init_val_x = -3*PI/2
        step_x = PI/2
        end_val_x = 3*PI/2

I really like the visual highlighting of things like PI, LEFT, TOP, BLUE, PURPLE, and to easily changing them. Is there maybe a way to use and enums and simultaneously keep BLUE_D instead of Colors.blue_d.value?

We could create aliases in the file containing the Colors enum:

class Colors(Enum):
    ...

RED = Colors.red
BLUE = Colors.blue
...

I agree, I kinda hate how it currently looks like with the Colors.blue_c.value. Not great. However, putting them all back as top level constants sort of defeats the purpose of this PR and we might as well close it.

So I say we do one of the following:

1. Instead of using an Enum, we can have colors be module attributes. So we can do either Colors.WHITE or from Colors import WHITE.

2. Instead of highlighting the color, we can highlight the module: COLORS.white, or even C.white as an alias.

To be quite honest, this something.value business loos pretty bad to me

With this approach:

# Colors
class Colors(Enum):
    """A list of pre-defined colors."""

    dark_blue = "#236B8E"

DARK_BLUE = Colors.dark_blue.value

we have the highlighting AND auto-completion

Ok so it seems like this is the state of things:

1. Con: the current way messes up with auto-completion.
2. Con: the current way requires us to import all constants at the same time, which is generally bad design.
3. Pro: the current way produces code that emphasizes the colors because their names are in ALL_CAPS.

This PR is replacing WHITE for Colors.white.value, which fixes the two "cons" but messes up the only "pro".

@kolibril13's suggestion fixes both "con"s and keeps the "pro"! The only part I don't like about it is that if we keep the colors inside the constants.py file then there are only two ways of accessing the colors: from constants import *, in which case you are still polluting the namespace ("con" number 2), or you have to import each color one at a time from constants import WHITE. If you want to import only the colors and not other constants you have to import the Enum and use Colors.white.value, which is ugly and messes up the "pro" number 3.

So I suggest that we keep @kolibril13's suggestion but in a separate file called colors.py. This will fix the two "cons", keep the "pro", AND allow for importing all colors (and only the colors) without importing other constants. You can even do something like import colors as C and use C.WHITE throughout your code. In fact, this is the way I would suggest we adopt this across the whole codebase. It's clean, it allows auto-completion, it emphasizes colors while still being short, it's unambiguous as to where WHITE was defined, and it only brings one name to the namespace when importing it.

EDIT: tagging @PgBiel as he was one of the main supporters of the Enum.

I agree with @kolibril13 .

So I suggest that we keep @kolibril13's suggestion but in a separate file called colors.py. This will fix the two "cons", keep the "pro", AND allow for importing all colors (and only the colors) without importing other constants. You can even do something like import colors as C and use C.WHITE throughout your code. In fact, this is the way I would suggest we adopt this across the whole codebase. It's clean, it allows auto-completion, it emphasizes colors while still being short, it's unambiguous as to where WHITE was defined, and it only brings one name to the namespace when importing it.

This is better IMO.

Just pushed some changes that reflect the discussion above. Please review!

I have just an issue with that; so If I understood correctly there are two ways to access a color, which are

C.COLOR
and
Color.white.value

Isn't that inconsistent? Both or none of them should use value.

(This is for me non-blocking),

Thanks for taking a look.

I agree it's inconsistent. In my mind, I think we should just support C.WHITE, and nothing else. We can do this by making the Colors Enum private, i.e. renaming it as _Colors or something like that.

In colors, line 124 is nice and compact, however, with this approach, we will lose autocompletion and (at least my) IDE throws a red warning. Note that the scene is still running properly.

So I would change line 124 explicitly to

WHITE = Colors.white.value
....

Then we have auto-completion and no warnings

I think this closes #81

So I would change line 124 explicitly to

WHITE = Colors.white.value
....

Then we have auto-completion and no warnings

If we do this, then I don't see a reason to use Enum at all.

Tagging @PgBiel who was one of the main supporters of Enum. Thoughts?

Marking as draft as this needs more discussion before it's merged.

So this needs a bit of rethinking. Anybody have any thoughts?

Closing in favor of #488